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Abstract - A video server system provides many different 
types of Interactive video services Including: video on 
demand, home shopping, Interactive games, etc Both the 
use of the Interactive video services and the video server 
itself need managing. This ranges from configuring the 
system, handling and logging faults, through monitoring 
the performance, etc This paper describes how to 
structure the Management Information Base (MIB) for 
managing DA VIC compliant video server systems. It is 
described in terms of the management protocol developed 
by Internet Engineering Task Force (IETF) known as 
.Simple Network Management Protocol (SNMP). 

O I. INTRODUCTION 

3ie term Network Management is often used to describe 
"management of more than just networks. Indeed, many of 
file techniques and tools developed for monitoring and 
goo trolling a network are equally suited to management of 
SCstributed systems. This is the case with video server 
'systems. This paper describes bow the network management 
'concepts and tools developed by the IETF (Internet 
CEhgineenng Task Force) under the banner of SNMP (Simple 
y^erwork Management Protocol) can be applied to video 
i^rvers. 

^fhis section describes the general concepts of management 
land introduces some of the features of SNMP. Section D 
iOvers some of the key areas for management of video sever 
systems. It then describes how SNMP MEBs can be defined 
to instrument these areas. This is based on the draft MIBs 
being defined by the Digital Audio Visual Council (DA VIC). 
In section III, we consider some of the security implications 
of using SNMP and identify some measures we can take, 

A Network Management Concepts 
Aspects of Management 

It is traditional to divide network and system management 
into 5 aspects representing the main management tasks: 
Fault' Configuration, Accounting, Performance, and 
Security. 



• Fault Management: It encompasses fault detection, 
isolation, and the correction of abnormal behaviour of 
the system. The fault may be permanent or transient 
Faults may be detected by events or by polling. A single 
fault may manifest itself as several events. Hence, fault 
management must be capable of correlating several 
events to determine the true fault 

• Configuration Management: This aspect of 
management is concerned with the configuration of the 
system. It involves starting and stopping components of 
the system, changing the parameters used to control the 
system, and changing the software and / or hardware. 

• Accounting Management: It determines the use an 
individual user makes of the system with the aim of 
informing the user of costs incurred or resources used. It 
is also involved with setting of accounting limits and 
tariff schedules associated with particular resources. 

• Performance Management* It is concerned with 
monitoring the behaviour of resources. It is used for 
provisioning planning and preventative maintenance. 

• Security Management: It is used to implement the 
security policies. These include control of authentication 
keys, user access permissions and confidentiality. 

Levels of Management 

Another way of looking at network and system management 
is to divide it into levels spanning the 5 functional aspects. 
Each level represents a different level of detail. There is a 
part of each aspect of management in each level. 

• Element Management: This is the lowest or most 
detailed level of management It is concerned with the 
monitoring and control of individual components of a 
system. In interactive video systems, this corresponds to 
monitoring and control of the individual hosts in a video 
server system and of the other networking equipment 
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• System Management: This level puts together the 
information from separate elements to provide a 
complete view of some pan of the system. This gives 
integrated management of the elements within the 
subsystem. 

• Service Management: Service management is 
concerned with management of the services provided by 
the system as seen by the users. In video interactive 
systems, this includes monitoring and control of the 
video on demand service, home shopping service, 
interactive games service, etc. 

• Business Management: Business management is 
concerned with setting business policy for the system 
and receiving summary information concerning the 
operation of the system and the services provided. 

The focus of this paper is on element management. That is, 
getting the raw data and providing low level control upon 
which the other levels of management can be based. 

^ B. Use of SNMP for Element Management 
j2 For element management we need to be able to monitor and 

set individual components within the video server system. 
kJ There are two aspects to this. Firstly is the specification of 
Q the components to be managed. These are usually referred to 
%\ as managed objects. A collection of managed objects is 

termed management information base or MIB. Secondly, we 
TZ need a protocol to read and write these managed objects. 
KJ There are two standard element management protocols: 

ISO's Common Management Information Protocol (CMP 
s_ (1J) and IEIFs SNMP [3J. 

! n SNMP is preferred over CM IP for several reasons including: 

1. Widely implemented: SNMP is available on most 
V? operating systems. 

2. Cheap to Implement: There are several tools which 
O make it easy to implement video server specific SNMP 
£ MIBs. 

3. Widely supported: Most Network Management Stations 
support SNMP. 

4. Functionally sufficient: Provides most of the 
functionality required - although filtering of data at 
source would be preferred. 

5. Standard MIBs: these cover much of the basic 
monitoring and control of the video server hardware. 
There are several widely used tools which use these MIB 
objects to report managemeni information. 

The main objections to SNMP are its weak security and 
inability to return multiple entries from a table or to filter 
returned values. These objections are resolved in SNMPv2 



[9] which is currently going through the IETF standards 
process. 

SNMP only supports operations to GET and SET (read and 
write) managed objects. All changes in state occur by side 
effect of setting managed object(s) to specific values. There 
are no CREATE, DELETE, ENABLE, nor DISABLE 
operations. 

SNMP also supports an asynchronous operation which can 
be raised by an agent called a TRAP. Tbis is used to signal 
exceptional events or alarms. The TRAP PDU is sent to 
multiple destinations. It is unacknowledged to keep the agent 

simple. 

In summary, SNMP provides the basic functionality for 
element management. Using the SNMP Structure of 
Management Information (SMI) notation, it is possible to 
define all the elements which need monitoring and through 
which control is achieved. The next section describes how to 
apply SNMP to video server systems. 

II. VIDEO SERVER MIB STRUCTURE 

A Motivation for Management of Video Server System 

Video server systems, as part of the overall video interactive 
systems* need managing. We will look at three particular 
users of management; customer care center, field service. 
and business management. They have different needs of 
management information and control. 

Customer Care Center needs knowledge of the current state 
of the video server system. For example, the operators need 
to know which users have been affected by a failure within a 
video server system. Operators need also to be able to 
register new users and change the rights of existing users in 
response to user requests. 

Field Service need to identify faults in the hardware 
platform of the video server and failures in the software. 
They are also interested in trends in recoverable failures such 
as packet loss or recoverable disk failures. These trends are 
used for preventative maintenance. Tbey need to be able to 
change the configuration of the video server system, for 
example, to install a new version of the software or alter 
some operational parameter. 

Business Management is interested in usage trends for 
capacity planning and tuning of business policy. Also need 
actual usage data for billing purposes. They need to be able 
to initiate the change in content of the video server and to 
alter the tariffs for usage. 
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B. DAVIC Server Architecture 



| Internal Network 




^Tbe Digital Audio Visual Council (DAVIC) server 
^architecture consists of several logical elements: service 
(jngateway, stream, application, and content The service 
Ungate way mediates all user access to toe video server. It 
J maintains the user profiles and can authenticate a user 
L/equesi for a session. It also supports downloading client 
^—applications to the set top boxes (STBs). Stream and 
U]applicatioD elements are allocated to a session based on the 
ryrequested services. The stream elements are launched to 
Support VOD (Video On Demand), NVOD (Near VOD) and 
^broadcast applications. The content element is used to 
Mmanage the video content of the video server. It is the way 
zpaew content is loaded and moved internally to the video 
server. 

The elements are linked to set top boxes via interfaces into 
the delivery network. There is a slow speed connection used 
to establish sessions. This is via the Service Gateway 
element Also, there are interfaces into the high speed 
delivery network for communicating MPEG streams. The 
interfaces used by the STBs are referred as S3, S4 (for 
control) and SI and S2 (for user requests and video stream). 
This follows the distinction in DSM-CC [11] of separate 
interfaces and protocols for user-to-network (U-N) and User- 
to-user (U-U). Inert is a separate interface used for 
management This is designated S5. 



The S5 interface allows a network management station 
(NMS) to monitor and control a video server system. Each 
element has to support the relevant part of the S5 interface. 
This allows monitoring and control of the elements. S5 uses 
SNMP as the access protocol. Network management stations 
may access S5 via the delivery network or some other private 
network. It is connected to the internal communications 
network to allow access to the network management agents 
of the elements. 

The S5 interface is also used to monitor and control the 
underlying video server framework - the hardware and 
middleware - which supports the video server elements. For 
example, this will allow monitoring of the computer nodes, 
disk activity and network traffic on the physical network 
interfaces. It can also be used for changing the configuration 
of the video server system. This monitoring and control of 
the framework will use a combination of standard MIBs and 
vendor specific MIBs. 

Note, this does not mean that each element has to have its 
own SNMP agent executing on the same node as the clement 
itself. Rather, proxy agents executing on another node can be 
used if desired. 

C. Monitoring points for Video Server Systems 

This section identifies some of the key monitoring and 
control points for management of a video server system. 

• Communication Interfaces: A video server system will 
have several physical interfaces into the delivery 
network. These are to support the SI. S2, S3 and S4 
services. In addition, there may be other interfaces for 
S5 access. These are monitored to detect loading and 
error rates, etc. Much of the monitoring can be 
performed using existing standard MIBs. 

• Video Server Framework: The hardware and 
middleware providing a video server system needs to be 
monitored for faults and performance. Management is 
also used to control the video server. Some of the 
monitoring can be performed using standard MIBs but 
much will be video server specific. Management is also 
used to configure the supporting framework. 

• Service Gateway Element: This element is used to 
process all end user requests for a service. It contains the 
user profiles, knowledge of resources in use. list of 
active sessions, etc. Network management can be used to 
query the above information and potentially used for 
control. For example, it could be used to terminate a 
session or stream. 
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• Streams Element: Management needs to be able to 
query the active streams and potentially to terminate a 
stream. It should be possible to relate a stream with the 
end user and the local access point into the delivery 
network. 

• Application Elements: there are many types of 
applications. Each type will have a specific MTB. 
However, there are several common features of all 
applications, such as which users are using the 
application, which interfaces into the delivery network 
are being used, etc. This application information can be 
included in a common application MIB. 

• Content Element: This element provides the means to 
monitor and control the content of the video server. 



D. MIB Structure 

Each element type provides a distinct set of functions. 

Therefore, we can structure the MIBs to represent this 

division of functionality. Each element type has its own set 
^ of managed objects. These are provided by separate MIB 
Sf definitions - one per dement type. This division permits the 

introduction of new element types without having to modify 
Q existing MIBs, e.g. a new application. Currently, DAV7C 
□ has draft specification for the following MIBs [10]: 

SJ 

~~ • Service Gateway MIB: This MIB has tables for 
sessions, user profiles, and applicaiion had The 

"Jj sessionTable lists the active sessions with this video 

U 1 server system. It identifies the end user associated with a 

5 session and any associated streams and/ or application 

p elements. The User profile and application load tables 

i n contain information used when initiating a session. 

Li * Stream Element MIB: This lists the streams active 
with this element It identifies the content being played 
p out, the current state (play, fast forward, pause, etc.) and 
Jc position. It also identifies the end user and the local 
interface through which the stream is being played out 
There are also counters for the total number of streams 
played, aborted, and rejected. 

• Application MIB: This is a generic MIB for all 
applications other than Video On Demand. It identifies 
the end user of the application and the local interface 
being used by the stream. 

• Content MTB: There are several tables which identify 
the content of the video server system. This includes 
identifying who provides the content and the content 



type as well as specific information about the content 
itself. 

SNMP was deliberately kept simple. There are no 
constructed data types, only simple objects (INTEGER, 
Counter, Gauge, OCTET STRING, Display String, etc.) A 
MIB definition consists of managed objects of these simple 
types. In addition, SNMP supports the notion of tables. Each 
row in the table consists of one or more managed objects, the 
number and type being defined in the MIB. There can be an 
arbitrary number or rows in the table. Each row is uniquely 
identified by an index. 

To illustrate the approach taken in the draft DAVTC MIBs, 
we will discuss the Streams Element MIB and the Sessions 
Group in the Service Gateway MIB. Only sufficient 
fragments of the MIBs are included for the discussion. 

Streams Element MIB 

The streams Element MIB contains several counters, some 
TRAPs and the streamTable. The counters record the 
number of streams initiated, rejected and aborted with this 
streams element. The TRAPs are used to report on 
exceptional changes in state of a stream such as rejections, 
aborted streams, and communications problems. 

The definition of die streamTable is as follows: 

stream Fn try OBJECT-TYPE 

SYNTAX StreamEotry 
ACCESS non-accessible 
STATUS mandatory 
DESCRIPTION 

M Tabic of active streams with this streams clement'* 
INDEX ( streamlodex. 

stream Sessionld, 

streimlflnricx) 

::= { streamTable 1) 

SoeamEntry ::= SEQUENCE 
{ 

streamlndex INTEGER, 
strcamlflodcx INTEGER. 
srrcamSessioald INTEGB*. 
streamType INTEGER, 
streimB and wi<fth INTEGER. 
strumDirectioo INTEGER, 
streamPositioo INTEGER. 
streamState INTEGER, 
streamRowStatus RowSuuk 
1 

Each stream in a streams element will have its own entry in 
the streams table. The meaning of each field is: 
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• streamlndex - a unique identifier for this stream entry. 

• streamlflndex - index into the standard MIB-D ifTable. 
This identifies the local network interface into ibe 
delivery network being used by this stream. 

• streamSessionid - index into the sessionTable in the 
Session Element MIB. 

• streamType - MPEG-2 or H-261 stream 

• streamBandwidih - measured in Mbps 

• streamDireciion direction for stream relative to set top 
box 

• streamPostiion - measured in second from the start 

• stTcamStau - state of the stream. Play, Ffwd, Rwd. Pause. 

• streamRowStaius - used to control the entry* including 
deleting (he stream. 

Session Service Group 

This group is part of the Server Gateway Element MIB. It 
records the current sessions and TRAPs for unusual events 
related to sessions. There is also a sessionTable which 
records the currently active sessions. 

3^uionEntry OBJECT-TYPE 
Q SYNTAX SessioaEotry 

Q ACCESS noo-KXcuiWc 

21 STATUS mandaiory 

^ DESCRIPTION 

Hi "list of current active sessioos" 

g INDEX ( sessiooladex } 

^SessiooEnoy SEQUENCE 
{sessionTable 1} 

in 

„ StreamEntry :~ SEQUENCE 
L, { 

sessionlndex INTEGER, 
U1 sessiooSessionld OCTET STRING (S1ZE(6)). 

nj sessionStarfTune DateAndTune, 

II icssiooEndTime DaieAodTime, 

ZZ sessionStrcams IpAddress. 

Q sessionApplicanoos IpAddress, 

sessions urus INTEGER. 
T ' r '~ sessionRowStatus RowStatus 

} 

• sessionlndex - is the unique reference of the session 

• sessionSessionld - identifier of this session used in 
protocols to and from STBs. 

• sessionStartTime - time this session started or is 
scheduled to start 

• sessionEndUme - time this session is due to end 

• sessionStreams - identifier of the stream supporting this 
session, if any. 

• sessionApplicaiions - identifier of the application 
supporting this session, if any. 

• sessionStaius - state of the session. 



• sessionRowStatus - used to control the session entry 
including delete the session. 

Note: the identity of the user of this session is not included in 
the sessionTable. Rather, there is another table of clients to 
the video server. Each entry contains a field sessionlndex. 
Using this field, it is possible to relate users with their 
sessions. 

Where possible, standard MIBs should be used. IETF have 
already standardized several communications oriented MIBs, 
the most important of which is MIB-D (RFC1213[4]). This 
is a generic MEB for monitoring the state of communication 
interfaces. The basic table in MIB-D is ifTable. There is an 
entry in this table for each interface in the system. This has 
counters for the number of octets / packets sent and received 
and the number of errors as well as the type of the interface 
and its current state. 

Rather than duplicating this information, the streamTable 
and applicmionTable reference the ifTable. For example, the 
streamslflndex is a reference into the ifTable. 

There are other MIBs which are interface type specific. They 
have managed objects for a particular interface type such as 
FDDI (RFC1512 [5]), and ATM (RFC1695 [8]). These are 
also keyed off iflndex. Hence, it is possible to browse through 
management information starting with a stream into the 
ifTable to get general information about the interface and 
onto a MIB for a specific network type. This is useful in fault 
finding and to correlate alarms. For example, if a particular 
interface fails, several streams are likely to be affected. For 
each one, a streamCommunicaiionTrap will be generated. 
This TRAP includes the iflndex of the affected interface. 

In addition to communications oriented MIBs, there are 
several MIBs designed for monitoring *bosts\ For example, 
the HOST MIB (RFC 1514 [6]) contains several managed 
objects and tables for monitoring host resources (disk, 
processor, memory etc.). Also, the Network Services 
Monitoring MTB (RFC 1565 [7]) defines a standard way of 
identifying the applications running on a node. 

There are several network management tools available which 
interrogate these standard MIBs. These tools may be for 
presenting a graphical view of system loading or for trend 
analysis, etc. By using the standard MIBs, where 
appropriate, in video server systems, these tools are available 
for monitoring and control. 

The Elements model for Video Server Systems Lends itself to 
a distributed implementation. To permit loosely coupled 
distributed implementations, we have to support distribution 
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of the MIBs. For example, to get the desired performance, a 
vendor may choose to implement the service gateway as well 
as the streams elements on one or more nodes. 

Each node supporting a streams element will have its own 
strcamTable. This will record only those streams being 
handled by that streams element A node providing the 
service gateway element will support the Service Gateway 
yrm This NUB contains the sessionTable. 

The basic SNMP model assumes all the MIBs run on the 
same node. For example. The link between one table and 
another is just the index into the other table. For a 
potentially distributed implementation, this is not sufficient 
information. Therefore, we use the IP address of the agent 
supporting the referenced MIB. 

Hence, in the DAVIC MIB, the sessionTable identifies the 
stream associated with a session by the sessionStreams field. 
This is the IP address of the SNMP agent supporting the 
corresponding strcamTable. It is not necessary to include the 
strcamJndcx, as the strcamTable is indexed by with the 
- scssionlndex. Thus, the following sequence of SNMP 
requests can be used to trace a session entry to a stream. 
□ Lookup the sessionStreams field in the sessionTable to 
O determine the IP address of the agent supporting the relevant 
B strcamTable. Then, using the scssionlndex value as the 
*Tj index, query the relevant SNMP agent to read the entry from 

~ the streamTablc. 

U? 

iJl All nodes, apart from the service gateway nodes, have a 

y] managed object which identifies the IP address of the service 

_ gateway node. An agent representing a Service Gateway 

Ft fpaintainc a table of other elements, the elementsTable (see 

f5 below). Using this table, it is possible to discover the SNMP 

r; : agents responsible for the other elements. 

ffl ckmentEntry OBJECT-TYPE 
q SYNTAX HcmeouEntry 

~T1 ACCESS not-accessible 

*¥* STATUS optional 

DESCRIPTION 

"The list of SNMP agents of this video server" 
INDEX (clementtfndex) 
(elementsTable 1} 

EkcneatsEntry SEQUENCE 
( 

elemeatlndex INTEGER, 
clementName Displays txing, 
clczDCofType DisplsyString, 
clemeatlpAddress Ip Address, 
elements ums INTEGER. 
elementRowStatus RowStatut 



• elementslndex - unique identifier of this entry 

• clementName - name of the node supporting the element 

• clemeniType * type of the element 

• elementlpAddress - address of the node supporting the 
element 

• clcmentStaxus - last known state of the element 

• elementRowStatus - indicates the state of the entry. 

The iJTablc. and other standard MIBs, are assumed to be 
local. Therefore, it is not necessary to use IP address when 
referencing these tables. 

Note, the draft DAVIC MIBs permit a single agent 
implementation. The IP addresses to other agents will be that 
of the node itself. The elementsTable need not be provided in 
this case. 

In addition to the DAVIC standard MIBs, vendors can 
provide their own MIB. This will enable monitoring and 
controlling their specific implementations. This is common 
practice in SNMP management The standard MIBs define 
managed objects for general monitoring and control. The 
vendor specific MIB may often be needed for specific 
management 

E. System and Service Management using MIBs 

In this section, we briefly discuss bow the DAVIC MIBs can 

be used for system and service management 

We can start and stop individual elements far bask 
configuration management TRAPs generated by individual 
elements can be used to initial recovery action where 
necessary for fault management The elementsTable in the 
service gateway element is useful to determine which nodes 
are supporting agents of this video server system. 

The strcamTable and applicationTable enable us to monitor 
the service being provided by the video server system. It can 
be used as the basis for billing as well as customer care 
should there be a failure. It can also be used for management 
of the content if desired. 

III. SECURITY CONSIDERATIONS 
It is necessary to protect networic management access to the 
Video Server System. Hie S5 interface uses well known 
protocols (SNMP over UDP) and the standard MIBs are 
public. Hence, we need security steps to prevent 
unauthorized changes or degraded performance. There are 
several options available. 
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A Physical Separation 

Provide a separate network for S5 interface from that used by 
the set top boxes. This ensures that onJy permitted NMSs can 
access the S5 interface. This is not always possible or 
desirable. For example, you may wish to allow remote access 
to field server engineers to diagnose a fault. 

B. Screend or Route Filtering 

Screend is an application which filters access based on 
source and destination IP address and port number. SNMP 
requests are carried on UDP and sent to the SNMP request 
port number 161. We know the set of network management 
stations which are authorized to access the video server 
MlBs. Hence, we can filter out all UDP messages to port 161 
unless it comes from a recognized and authorized network 
management station. However, IP addresses can be faked. 

C. Community Name 

SNMP has the notion of communities. An SNMP 
administrator can limit access to particular MDB variables on 
3 community by community basis. Each request contains a 
^bmmunity name. The video server administrator will 
Lvalidaie the use of this community name against the source 
fgddress. If that community is not authorized from that source 
address, then the agent refuses the request and issues an 
: r£uihemicationFailure TRAP. As some objects may be 
considered more sensitive than others, then we can use 
yfifferent community names. For example, it is common to 
LQse the community name public for reading the system 
[group in MIB-II. 

ID. SNMPv2 Secunty Features 

!~jhe IETF recognize that one of the main shortcomings of 
ytne tint version of SNMP was its lack of security. This is 
feeing addressed in SNMPv2. When SNMPv2 stabilizes, then 
r&s security features should be used. 

*p IV. SUMMARY 

SNMP provides a suitable basis for element management of 
a video server system. It is widely deployed for managing 
data networks and there are already many tools and network 
management stations which could be used to manage a video 
server system and the entire video interactive system. 

This paper has shown the approach being taken in DA VIC 
for managing the elements of a video server system. In 
particular, it defines how loosely coupled distributed 
implementations can be handled. The MTB specification 
effort has just started and much more work is needed. 
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